Subject: Welcome!

From: "Shannon Nix" <[email-masked]>
Date: Wed, 7 Jul 93 08:45:49 EST

Welcome to the DLSW siglet on flow control.  In order to bring new 
participants (or old ones) up to speed, I have posted pertinent excerpts 
from messages that have been exchanged to date.

Enclosed are those exchanges:
On Fri, 30 Apr 1993 10:56:00 +0000, J. wrote:

>Having just joined this discussion, and not having participated in the
>workshops (not through my own fault), I would appreciate some clarification
>on some of the suggestions for enhancements to DLS.  Please forgive me if
>I display my ignorance.
>
>>Novell's list of desirable DLS enhancements as of April 29, 1993 is:
>>
>>1. Flow Control 
>DLS is carried over TCP, which has flow control.  Further the individual
>sessions within the connection all have flow control.  What exactly is
>missing?
>
>Jim Cobban, BNR

On Fri, 30 Apr 93 08:28:25 PDT, <[email-masked]> wrote:

>>
>>>Novell's list of desirable DLS enhancements as of April 29, 1993 is:
>>>
>>>1. Flow Control 
>>DLS is carried over TCP, which has flow control.  Further the individual
>>sessions within the connection all have flow control.  What exactly is
>>missing?
>
>    If you're thinking of ICMP source quench as a means of TCP/IP flow
>    control ... dream on! (Just kidding ... it turns out no one has a
>    serious implementation of ICMP source quench.)  All SNA
>    internetworking vendors have been left to implement their own
>    (read: proprietary) form of flow control for both sides of a switch
>    element (i.e. flow controlling the SNA side when the TCP/IP network
>    is congested and flow controlling the TCP/IP side with the SNA
>    devices are congested).
>
>    cisco has it's own, IBM has it's own (though, as has been pointed
>    out, it's not documented), etc.  It essentially becomes a requirement
>    when you locally terminate the DLC connection at the router.
>
> Wayne Clark, Cisco

On Fri, 30 Apr 1993 15:35:00 +0000, J. wrote:

>In connection with flow control, my understanding of TCP/IP is certainly
>much less than that of many other members of this group.  My practical
>experience is limited to using the network from my workstation.  My
>theoretical experience derives from reading, in more or less detail, about
>150 of the RFCs plus another few dozen drafts.  That does, however,
>include Van Jacobson's papers on flow control in TCP/IP.  However I have no
>real personal experience in the area of flow control algorithms except when
>I have been a victim of their failure.
>
>I was not thinking of ICMP source quench, which even theoretically could not
>be used for effective flow control.  I simply assumed, because of the
>thousands of FTPs I have done over the past few years, that TCP/IP was
>capable of adapting to the capacity of the network connection so as to
>at least manage congestion, if not avoid it.  Isn't what TCP/IP does in
>selecting a window flow control?
>
>Jim Cobban, BNR

---

From: "Bernard Brady" <[email-masked]>
Date: Wed, 7 Jul 93 15:12:47 EDT

>>1.  Flow Control
>>
>>As stated previously by Dennis Wind in this forum, we are developing
>>an end-to-end mechanism for flow control that DLSw manages.  In our
>>mechanism, flow control is implemented by a new field in the SSP header.
>>This field resides at offset 1 and was previously marked as reserved.
>>It is piggybacked on all I-frames.  The format of the field is:
>>
>>  76543210
>>  X.......  -  Pacing Request Indicator (PREQ)
>>  .X......  -  Pacing Response Indicator (PRSP)
>>  ..X.....  -  Decrement Window Size Indicator (DWSI)
>>  ...X....  -  Inrement Window Size Indicator (IWSI)
>>  ....X...  -  Close Window Indicator (CWI)
>>  .....X..  -  Don't Count Frame Indicator (DCFI)
>>  ......XX  -  Reserved
>>
>>There are three new SSP's:
>>
>>  IPM (x'7C')
>>  ENTERBUSY (x'0C')
>>  EXITBUSY (x'0D')
>>
>>A pacing window is defined for each circuit.  Management of this window
>>is modelled after the VR windows defined for SNA NT 4.
>> - PREQ is set if the maximum number of I-frames has been received
>>   from the LAN without receiving either a IPM SSP or an I-frame with
>>   PRSP set.
>> - PRSP is set on the next WAN-bound frame if PREQ has been previously
>>   received on a I-frame on that circuit.  PRSP received on a circuit
>>   will clear any local RNR condition.
>> - DCFI is only set if pacing is not in use, i.e. the pacing window
>>   defined was set to zero.
>> - DWSI and IWSI have been defined for adaptive pacing.
>>   DWSI is set in conjunction with PRSP to cause the partner to halve
>>   the pacing window.
>>   IWSI is set in conjunction with PRSP to cause the partner to increment
>>   the pacing window.
>> - CWI usage has not been defined yet.
>> - IPM is sent to the circuit partner if a PREQ has been
>>   received and there is no I-frame to piggyback the PRSP on.
>> - ENTERBUSY is sent to the circuit partner on detection of a remote
>>   RNR condition.  This will cause the circuit partner to enter a local
>>   RNR condition.
>> - EXITBUSY is sent to the circuit partner when a remote RNR condition
>>   clears.  This will cause the circuit partner to exit a local
>>   RNR condition.
>>

PREQ -

Shouldn't PREQ read something like this?

The  sending side of the circuit is allowed to send up to N (the window
size) requests at a time.  On the first request the sending side turns
on a pacing request .  After the receiving side receives the request
that contains the pacing request it can signal the sender with a pacing
response when it is ready to receive the next window of data.

The  sending side will signal a  DLC_ENTER_BUSY  to DLC when 
a  maximum number of I-frames has been received from the LAN without
receiving either a IPM SSP or an I-frame with PRSP set.

CWI -

I agree that by using CWI there is no reason for the ENTERBUSY and
EXITBUSY SSP messages.

DWSI and IWSI -

Is there any reason why either  DWSI and IWSI cannot be set while the
window is closed?

Without negotiation how does a sending side determine to half or 
increment  the receiving sides windows?

If you ask a peer to increment to a value it does not support  does it
ignore the request or take down the circuit?

Bernie